AWS再入門ブログリレー2022 AWS IAM編

AWS再入門ブログリレー2022 AWS IAM編

弊社コンサルティング部による『AWS再入門ブログリレー 2022』の31日目のエントリ『AWS IAM』です。
AWS再入門2022

AWS再入門2022

#AWS IAM
#図解
#AWS
千葉 幸宏（チバユキ）

千葉 幸宏（チバユキ）

facebook logohatena logotwitter logo
Clock Icon2022.03.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉（幸）です。

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の31日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2022 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今日のテーマは『 AWS IAM 』です。

このエントリは何を目指すのか

さっそくいってみましょう、

と軽快なスタートを切りたいところですが、そこそこのボリュームを持つエントリになってしまったので、どんな気持ちで読んでもらいたいかを先に書いておきます。

この再入門のコンセプトは先述の通りですが、如何せん IAM の世界が広大なのでどこをターゲットにするかに迷ってしまいました。初心者向け、経験者向け、ちょうどいい塩梅が思いつきませんでした。

なのでこのエントリはマニアックな方向け、という立て付けにしました。「普段そんな気にしてないけど裏ではそんな感じなんだね」というちょっとした気づきを与えられるように、というのがテーマです。別に知らなくてもそこまで困らない情報を厚めに提供するように心がけています。

とは言え最低限「再入門」というコンセプトは守っているので、入門用の記事としても耐えうる作りにはなっているかと思います。

このエントリで書かないことは以下のあたりです。

  • IAM 設計のベストプラクティス
  • IAM ポリシーの詳細やレシピ
  • その他テクニカルなこと全般

AWS IAM は 秒間 5 億アクセスの web サービスである

AWS IAM は web サービスです。AWS リソースへのアクセスを制御するのを助けてくれる web サービスです。具体的には、認証と認可により制御を行います。

そのイメージを示したのが以下図です。

例えばユーザーが AWS サービスにリクエストを送りたいとします。もう少し具体例を挙げるとわたしが EC2 インスタンスを新規作成したいとします。

わたしは何らかの IAM ユーザーのユーザー名とパスワードを入力し、マネジメントコンソールにサインインします。マネジメントコンソールから EC2 インスタンスの新規作成を実行すると、EC2 のサービスエンドポイントにリクエストが送信されます。そのリクエストはサービスエンドポイントを経由して AWS IAM にパスされます。そこで認証と認可が行われ、その結果により EC2 インスタンスの作成リクエストは許可ないし拒否されます。

AWS サービスへのリクエストの度にその裏で AWS IAM にリクエストが行われている、というのがポイントです。リクエストを受け付ける AWS IAM エンドポイントは数百万のホストによって提供されており、1 秒間に 5 億回のリクエストがあるとのことです。 *1すごい規模ですね。

認証と認可

認証と認可という言葉を使いました。それらの理解には以下のエントリに目を通していただくのが一番です。

大まかにいうと認証は「誰であるか」、認可は「何をしていいか」を司るものです。

先の例で言えばマネジメントコンソールにサインインする際のユーザー名とパスワードが認証に必要な情報となり、IAM ユーザーにアタッチされている IAM ポリシーが認可に用いられる情報です。

AWS IAM における認証情報は大きく以下があります。

  • マネジメントコンソールにサインインするためのパスワード
  • クレデンシャル（アクセスキーID、シークレットアクセスキー）
    • 一時的なクレデンシャルの場合はそれに加えてセッショントークン

AWS IAM での認可はいわゆる「IAM ポリシー」を含む各種ポリシーによってコントロールされます。これは後段で改めて取り上げます。

AWS リソースと AWS アカウント

基本的なところをおさらいしておきます。

EC2 インスタンスや S3 バケットといった各種 AWS リソースは、どこかの AWS アカウントに所属させて作成します。IAM ユーザーや IAM ロールも AWS リソースです。（文脈によっては AWS リソースと対になるコンポーネントとして取り上げられることもあります。）

AWS アカウントは AWS リソースをグルーピングする一番大きな箱で、12桁の数字を持つものです。AWS アカウントにはひとつのルートユーザーが紐付き、このルートユーザーを指して AWS アカウントと呼ぶ場合もあります。

ルートユーザーは以下の認証情報を持てますが、かなり強い権限を持つため通常は使用しないことが推奨されます。万が一漏洩した場合の被害が甚大になるためです。

  • メールアドレスとパスワードの組み合わせ
  • クレデンシャル（アクセスキー ID、シークレットアクセスキー）

代わりに IAM ユーザーや IAM ロールを作成し、その認証情報を用いることがベストプラクティスです。

クロスアカウントアクセス

AWS リソースは何らかの AWS アカウントに所属する、という話をしました。基本的にこの AWS アカウントを跨いだアクセスはできません。どこかの AWS アカウントに属する認証情報を使用して、別の AWS アカウントに属する AWS リソースにアクセスできない、と言う意味です。

とは言えすべてが NG な訳でなく、条件付きで成功することもあります。具体的には、対向の AWS リソースで許可が与えられていることです。この許可はリソースベースポリシーというものによって行われます。「リクエストの実行元」と「実行先の AWS リソース」が異なる AWS アカウントに所属する場合、そのアクセスはクロスアカウントアクセスと呼ばれます。

すべての AWS リソースでリソースベースポリシーを適用できるわけではなく、リソースベースポリシーに対応していないリソースではクロスアカウントアクセスはできません。上記のイメージだと、EC2 インスタンスや IAM ユーザーが該当していないリソースです。

「AWS レイヤ」へのアクセス

「アクセス」と言う表現が誤解を招きやすいので、少し補足しておきます。ここでのアクセスとは、AWS サービスにリクエストを送ることを指します。クロスアカウントアクセスとは、異なる AWS アカウントに属するリソースをターゲットにして AWS サービスにリクエストを送ることを指します。

例えば EC2 インスタンスに SSH 接続することは今回の文脈における「アクセス」ではありません。異なる AWS アカウントに属する EC2 インスタンス間の SSH 接続であっても、それをクロスアカウントアクセスとは呼びません。

イメージを表したのが以下です。

勝手に「AWSレイヤ」という表現が好きで使っています。通じないことが多いと思うので、よそでは使わないでください。

EC2 インスタンスを新規作成する、インスタンスタイプを変更する、アタッチする SecuriryGroup を変更するといった操作は「AWS レイヤ」へのアクセスです。OS ユーザーを作成する、ディレクトリのパーミッションを変更する、ファイルを新規作成する、などは「OSレイヤ」での作業です。 *2

AWS IAM で制御できるのも CloudTrail に記録されるのも AWS レイヤでのアクセスである、というイメージを覚えておくとよいでしょう。（AWS 初心者の方で、このあたりを混同されているケースを何度か見かけました。）

何をもってクロスアカウントアクセスだ、という話は以下もあわせてご参照ください。

AWS IAM の AWS リソース（IAMリソース）

AWS IAM というサービスにおける AWS リソースを取り上げます。主要なものとしてまずは以下を覚えておけば OK です。

  • IAM ユーザー
  • IAM ロール
  • IAM グループ
  • IAM ポリシー

もう少し細かいところまで押さえたい、という場合は以下を参照してください。

IAM アイデンティティとか IAM リソースとか IAM プリンシパルとか

今回取り上げる 4 つの IAM リソースはいろいろな呼ばれ方をします。別に覚えなくてもいいですが、頭の整理のためにかいた図を貼っておきます。

IAM Resources

ガチッとした定義はおそらくなく、文脈によって指す対象が変わることが多いです。自信を持って言えるのは IAM アイデンティティがユーザー、ロール、グループを指す、というところくらいです。

この 4 つのリソースの他にも、 IdP（ID プロバイダー）、セッションプリンシパル、フェデレーションユーザー、MFA などこの円のどこかに入りうるコンポーネントがありますので、上記の図を丸暗記してもいいことはありません。雰囲気でやっていきましょう。

IAM ユーザー

IAM ユーザーは、もっとも分かりやすい IAM における認証のためのリソースです。IAM ユーザーを作成後、以下の認証情報を生成できます。

  • マネジメントコンソールにサインインするためのパスワード
  • クレデンシャル（アクセスキー ID、シークレットアクセスキー）

IAM ロール

IAM ロールも 認証のために使用されるリソースです。IAM ユーザーとの決定的な違いは、IAM ロール自身がリクエストを送る主体にはならないという点です。

主体となるのは「IAMロールを引き受けたセッション」です。IAM ユーザーが IAM ロールを引き受けるケースを考えます。

AssumeRole

リクエスト元の IAM ユーザーは、AWS STS というサービスにリクエストを送ります。リクエストの内容は、指定した IAM ロールを引き受けたいというものです。そのリクエストが許可されると一時的なクレデンシャルが返却されます。以下の組み合わせからなるものです。

  • アクセスキー
  • シークレットアクセスキー
  • セッショントークン

先ほど見た IAM ユーザーで生成できるクレデンシャルは永続的なクレデンシャルと呼ばれ、セッショントークンが含まれません。つまり時間制限がないということです。一時的なクレデンシャルを使用してリクエストを実行する場合、その主体は「IAM ロールを引き受けたセッション」になります。引き受けた IAM ユーザーでもなく、IAM ロール自身でもありません。大事なことなので覚えておきましょう。

誰が IAM ロールを引き受けられるのか

以下の主体が IAM ロールを引き受けられます。

  • IAM ロールと同じ AWS アカウントの IAM ユーザー
  • IAM ロールと異なる AWS アカウントの IAM ユーザー
  • AWS サービス
  • 外部 IdP により認証された外部ユーザー

「AWS サービス」は正確には「AWS サービスが提供する web サービス」と記載されています。 *3

例えば EC2 インスタンス上のユーザー/アプリケーションが IAM ロールを引き受けたいとなった場合、インスタンスにアタッチされたインスタンスプロファイルを経由して EC2 サービスにリクエストが送られ、EC2 サービスが IAM ロールを引き受ける、という流れになります。（最終的にユーザー/アプリケーションに一時的なクレデンシャルが払い出されます。）

また、SAML 2.0 や OIDC と互換性のある IdP によって認証された外部ユーザーが引き受けることもできます。例えば Active Directory と AWS IAM をフェデレーションし、AD ユーザーと IAM ロールのマッピングをしたとします。AD ユーザーとして認証が済んだ状態で専用のエンドポイントにアクセスすることで、特定の IAM ロールを引き受けた状態でマネジメントコンソールにサインインする、といった方式が可能になります。こういった外部ユーザーはフェデレーテッドユーザーと呼ばれることもあります。

AssumeRole AWS Service federated User

誰が IAM ロールを引き受けられるかをどう制御するのか

信頼ポリシーによって制御します。

IAM ロールには IAM ユーザーと同じように IAM ポリシーをアタッチできます。これにより「IAM ロールを引き受けたセッションが何をできるか」が制御されます。それとは別に信頼ポリシーと呼ばれるポリシーもアタッチでき、それによって「誰が IAM ロールを引き受けられるか」が制御されます。

この信頼ポリシーは分類としてはリソースベースポリシーというものに属します。ここまでに何度か出てきましたね。この後の「IAM ポリシー」の節でもう少し深掘りします。

IAM グループ

IAM グループは IAM ユーザーや IAM ロールと異なり認証情報を持ちません。認可を司る IAM ポリシーを効率的に配布するための枠だと思っておけばいいでしょう。

IAM グループには IAM ユーザーを所属させることができ、IAM グループにアタッチされた IAM ポリシーはグループ内のユーザーに継承されます。言ってみればできることはそれだけです。IAM ポリシーの中でもアイデンティティベースポリシーと呼ばれる特定のタイプのみが IAM グループへのアタッチに対応しています。

以下はできません。

  • root ユーザーを所属させる
  • IAM ロールを所属させる
  • IAM グループを所属させる（ネストさせる）

IAM ポリシー

IAM ポリシーは認可を司るリソースです。

IAM におけるポリシータイプは以下の 6 つがあります。 *4

  • アイデンティティベースポリシー
  • リソースベースポリシー
  • アクセス許可の境界（Permissions boundary）
  • Organizations SCP
  • アクセスコントロールリスト
  • セッションポリシー

広い意味では上記全部を引っくるめて IAM ポリシーです。ただ、単に IAM ポリシーと言う時にアイデンティティベースポリシーだけを指すことも多いです。文脈から判断しましょう。

全部は深掘りできないので、いくつかピックアップして記します。以下エントリもあわせてご参照ください。

IAM JSON ポリシー

アクセスコントロールリスト以外のタイプの IAM ポリシーはすべて JSON 形式で定義されます。その要素は以下にまとめられています。

ここでの定義により許可、あるいは拒否の認可が行われます。

アイデンティティベースポリシー

IAM アイデンティティ（ユーザー、ロール、グループ）にアタッチできる、いわゆる IAM ポリシーです。Permission Policy と呼ばれることもあります。

以下のように種類分けされています。

  • 管理ポリシー
    • AWS 管理ポリシー
      • （職務機能の AWS 管理ポリシー）
    • カスタマー管理ポリシー
  • インラインポリシー

管理ポリシーは独立したリソースです。どの IAM アイデンティティにアタッチされていない状態でも存在できますし、複数のアイデンティティで共有することもできます。

インラインポリシーは IAM アイデンティティに埋め込まれた形で存在するものであり、アイデンティティのパラメータの一つとして考えた方が実態に近いかも知れません。

リソースベースポリシー

リクエストの対象となる AWS リソース側にアタッチするポリシーです。

すべてのリソースがリソースベースポリシーに対応しているわけではありません。対応しているリソースは以下から確認できます。（正確には対応しているリソースを持つサービスかどうかが確認できるので、そこからさらにページ遷移して確認する必要があります。）

リソースベースポリシーではPrincipal要素を含めることができ、その要素によりリクエストの実行元を制御できます。

Principalで指定できるプリンシパル（実行元）は以下です。IAM グループが含まれていないことに注意してください。

  • AWS アカウントおよびルートユーザー
  • IAM ロール
  • ロールセッション
    • Assumed-role セッション
    • ウェブ ID セッション（信頼ポリシー用）
    • SAML セッション（信頼ポリシー用）
  • IAM ユーザー
  • AWS STS フェデレーテッドユーザーセッション
  • AWS サービス
  • すべてのプリンシパル（匿名ユーザー）

「信頼ポリシー用」と書いてあるのはその名の通り信頼ポリシーのPrincipalでのみ使用できるプリンシパルタイプです。後で出てくる AWS STS の項で改めて触れます。

プリンシパルとエンティティとは何か

プリンシパルという言葉が出てきたので改めてその内容を確認します。

principal という英単語を調べると、主役、本人といった意味があるようです。リクエストの実行主体、という捉え方がしっくりきます。

AWS ドキュメントでは以下のように説明されています。

プリンシパルは、AWS リソースのアクションまたはオペレーションに対してリクエストできるユーザーまたはアプリケーションを指します。プリンシパルは、AWS アカウント のルートユーザー または IAM エンティティとして認証され、AWS にリクエストを行うことができます。ベストプラクティスとして、ルートユーザー 認証情報は日常業務に使用しないでください。代わりに、IAM エンティティ (ユーザーおよびロール) を作成します。フェデレーティッドユーザーやプログラムによるアクセスをサポートし、AWS アカウントへのアクセスをアプリケーションに許可することもできます。

難しいですね。ドキュメントのちょっと上を読むと、以下の文言もあります。

AWS アカウント にサインインし、リクエストを作成するために AWS のルートユーザー、IAM ユーザー、または IAM ロールを使用する人またはアプリケーション。プリンシパルには、フェデレーティッドユーザーと引き受けたロールが含まれます。

難しいですね。

プリンシパルと一緒にエンティティという言葉もよく使われます。エンティティは「実体」という意味を持つようです。

わたしの中での理解はこうなっています。

what is Principal

狭い意味でのプリンシパルは AWS の世界で実体を持たない主体です。たとえばわたしです。Systems Manager エージェントといったアプリケーションも AWS の世界では実体を持ちません。

それらのプリンシパルが AWS サービスにリクエストを送りたい場合、なんらかの認証情報を使用する必要があります。そのために、AWS の世界で実体（エンティティ）を持つものを利用します。認証に使用できる IAM エンティティとしては IAM ユーザーと IAM ロールがある、というのはここまで見てきた通りです。

IAM エンティティで認証した状態、例えば IAM ユーザー A を使ってマネジメントコンソールにサインインしたわたし、を指してプリンシパルと呼ぶこともあります。こちらが広い意味でのプリンシパルです。リソースベースポリシーのPrincipal要素で指定することになるのは広義のプリンシパルです。

これがわたしの理解です。このあたりは気にしなくても別に困らないのですが、言葉の意味をどう捉えたらいいんだ……？となった時に思い出していただければと思います。

AWS STS（Security Token Service）とは何か

ここまで何度か登場してきた AWS STS ですが、改めてそれが何かを確認します。

AWS STS は AWS サービスの一つです（あるいは一つと言っていいと思います）が、単体で利用することはありません。一時的な認証情報を作成・提供することで AWS IAM というサービスを補助してくれるサービスです。AWS IAM という製品のサブプロダクトである、という偉大な先人の表現が気に入っています。

AWS STS による一時的な認証情報の提供

一時的な認証情報を取得する AWS STS オペレーションは以下があります。

  • AssumeRole
  • AssumeRoleWithSAML
  • AssumeRoleWithWebIdentity
  • GetFederationToken
  • GetSessionToken

AssumeRole、GetFederationToken、GetSessionTokenの違いは以下にてイメージを記載していますのであわせてご参照ください。

リクエストの実行元とターゲット、それによって得られた一時的な認証情報を使用するプリンシパルをまとめたのが以下です。

AWS STS temporary credentials

先ほどリソースベースポリシーのPrincipal要素として指定できるプリンシパルとして以下を挙げました。

  • AWS アカウントおよびルートユーザー
  • IAM ロール
  • ロールセッション
    • Assumed-role セッション
    • ウェブ ID セッション（信頼ポリシー用）
    • SAML セッション（信頼ポリシー用）
  • IAM ユーザー
  • AWS STS フェデレーテッドユーザーセッション
  • AWS サービス
  • すべてのプリンシパル（匿名ユーザー）

このあたりがとてもややこしいのですが、Principal要素では「一時的な認証情報を使用するセッション」自体を指定することも、その認証情報のベースとなったターゲットを指定することもできます。

例えば IAM ロール自身がリクエストを実行することはないのにPrincipalとして IAM ロールを指定できる、ということです。意味合いとしては「このロールを引き受けたセッションをまとめて指定する」というイメージですが、セッション単位で指定するときと稀に挙動が異なります。この辺りは深掘りすると沼なので今回は取り上げるのをやめます。 *5

フェデレーテッドユーザー

Principal要素に指定できるプリンシパルとして「AWS STS フェデレーテッドユーザーセッション」がありました。これはsts:GetFederationTokenにより生成されたフェデレーテッドユーザーのことを指します。IAM ロールの節で「外部 IdP で認証された外部ユーザーをフェデレーテッドユーザーと呼ぶこともある」という話をしましたが、それとは異なります。

フェデレーテッドユーザーという言葉が出てきたときに、どれを指しているかを区別するとよいでしょう。

外部 IdP のユーザーはsts:AssumeRoleWithWebIdentityもしくはsts:AssumeRoleWithSAMLによって IAM ロールを引き受け、「IAM ロールを引き受けたセッション」としてプリンシパルになります。例えばこのプリンシパルからのリクエストを許可するために S3 バケットのリソースベースポリシーを定義するとしたら、Principalで指定するのは以下になります。

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

もう少し広めに以下のような書き方をすることもできます。どの単位で制御したいか次第となります。

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

外部 IdP ユーザーが IAM ロールを引き受けるために、その IAM ロールの信頼ポリシーで定義される必要があるPrincipal要素の書き方が以下です。

"Principal": { "Federated": "web-provider-name" }

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

これらを S3 バケットのリソースベースポリシーに書いても意味を成しません。ややこしいですが覚えておきましょう。

AWS へのリクエスト

最後に AWS へのリクエストの一連の流れを押さえて終わりにします。冒頭のイメージをもう少し肉付けすると以下のようになります。

AWS IAM request sin

プリンシパルは何らかの手段で AWS サービスにリクエストを送ります。手段は大きくマネジメントコンソールかそれ以外か、に分類されます。

マネジメントコンソールの場合はコンソール経由で、それ以外のプログラムアクセス（AWS CLI、AWS SDKなど）の場合は直接アクセスで AWS サービスエンドポイントにリクエストを送信します。（一部例外はあります。）

AWS サービスに送信されたリクエストは AWS IAM にパスされる、というのは先述の通りです。IAM においては AWS enforcement code というものによって認証と認可が行われます。

AWS リクエストに含まれる情報

リクエストには以下の情報が含まれます。

  • アクションまたはオペレーション
    • 例えばs3:PutObjectなど
  • リソース
    • リクエストのターゲットとなる AWS リソース
  • プリンシパル
    • プリンシパルの情報
    • プリンシパルに関連づけられたポリシーの情報など
  • 環境データ
    • IPアドレス
    • ユーザーエージェント
    • SSL 有効ステータス
    • 時刻　など
  • リソースデータ
    • ターゲットのリソースのデータ（名称、タグなど）

これらの情報はリクエストコンテキストに収集され、リクエストの評価と認可に用いられます。

AWS リクエストへの署名

リクエストに含まれる情報は上記の通りですが、認証プロセスをパスするためには署名を加える必要があります。これまで見てきた認証情報は、この署名の中で用いられます。

署名そのものについては詳しく取り上げる時間も技量もないので詳細は以下をご参照ください。

ざっくり、以下のような各種情報の組み合わせと計算により生成されます。

Sigv4-add

手動で署名を作成することもできますが、実践した機会がある方は少ないでしょう。AWS CLI や AWS SDK といったツールを使う際には、それらが自動で行なってくれています。（公式情報は見つかりませんでしたが、マネジメントコンソールでも裏でいい感じにやってくれていると思います。）

ごく一部の認証が不要なリクエスト以外は、この署名が必ずセットになっています。この署名の内容が正しくないと、認証プロセスの段階で弾かれます。

リクエストコンテキストの値を用いた認可

リクエストに含まれる情報がリクエストコンテキストに収集される、という話は既にしました。

その値を元に、AWS enforcement code が認可を行います。認可においてはポリシーが大きな意味合いを持ちます。さまざまなポリシータイプが統合的に評価され、最終的に拒否か許可の判断が下されます。

もう少しパターン分けすると以下の通りとなります。

  • 暗黙的な拒否：ポリシーで許可が与えられていないことによる拒否（デフォルト）
  • 明示的な拒否：ポリシーで拒否が定義されていることによる拒否
  • 許可：明示的な拒否がなく、許可がある場合

この評価の論理が特に IAM の中でも難しいところで、わたしが最も好きなところでもあります。ここでは語り切れないほど愛でたことがあるので、興味がある方は覗いてみてください。

ちなみに上記のエントリに載っているフローチャートではクロスアカウントアクセスが考慮されていないので、その道のりの険しさが実感させられます。

この図もあわせて覚えておくと役立つかと思います。（共に AWS Identity and Access Management (IAM) Part1より）

policyevaluationlogic

policyevaluationlogic-7514836

これで AWS へのリクエストの一連の流れはおしまいです。

ようこそ、IAM の世界へ

IAM に再入門してみました。やばい世界だな、ということの一端が伝わっていれば何よりです。

泣く泣くカットした情報はいくらでもあるのですが、話の流れにうまく組み込めなかったトピックをここで供養しておきます。

  • IAM では追加の認証情報として MFA を使用できます
  • IAM コントロールプレーンと IAM データプレーンっていうのが分かれているらしいよ

ここまでで『AWS 再入門ブログリレー 2022』の 31 日目のエントリ『AWS IAM』編はおしまいです。

次回、3/18(金)は Takuya Shibata さんの「AWS Tools for PowerShell」の予定です。お楽しみに！！！！

以上、 チバユキ (@batchicchi) がお送りしました。

参考

脚注

  1. AWS re:Invent 2021 - Keynote with Dr. Werner Vogels - YouTube ↩
  2. インスタンスを「停止する」というのは AWS レイヤからでも OS レイヤからでもできる、という考えです。後者の場合、OS レイヤでの停止操作に伴い AWS レイヤのインスタンスの停止が行われる、というイメージでいます。 ↩
  3. Roles terms and concepts - AWS Identity and Access Management ↩
  4. IAM でのポリシーとアクセス許可 - AWS Identity and Access Management ↩
  5. 興味があればこちらをご覧ください。IAM 評価論理ファン必見！AWS ドキュメントにリソースベースポリシー評価論理のプリンシパルごとの違いが記載されました | DevelopersIO ↩

Share this article

facebook logohatena logotwitter logo

関連記事

特定の IP アドレス または CloudShell からのみ S3 バケットにアクセス可能に制限する方法を教えてください

特定の IP アドレス または CloudShell からのみ S3 バケットにアクセス可能に制限する方法を教えてください

User avatar
かねこ
2024.11.22
S3バケットへのアクセスをオンプレミスサーバーのプライベートIPアドレスで制限する方法2選

S3バケットへのアクセスをオンプレミスサーバーのプライベートIPアドレスで制限する方法2選

User avatar
平井裕二
2024.11.19
AWS CLIを使用したJumpアカウントでのスイッチロール後、非許可IPアドレスからの操作が可能になる理由と対策

AWS CLIを使用したJumpアカウントでのスイッチロール後、非許可IPアドレスからの操作が可能になる理由と対策

User avatar
平井裕二
2024.11.18
IAMユーザのシークレットアクセスキーをSecret Managerに保管しローテーションさせてみた

IAMユーザのシークレットアクセスキーをSecret Managerに保管しローテーションさせてみた

User avatar
S.D.
2024.11.07
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.